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Abstract. The behaviour produced by an instruction sequence under 
execution is a behaviour to be controlled by some execution environment: 
each step performed actuates the processing of an instruction by the exe- 
cution environment and a reply returned at completion of the processing 
determines how the behaviour proceeds. In this paper, we are concerned 
with the case where the processing takes place remotely. We describe 
a protocol to deal with the case where the behaviour produced by an 
instruction sequence under execution leads to the generation of a stream 
of instructions to be processed and a remote execution unit handles the 
processing of that stream of instructions. 
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1 Introduction 

The behaviour produced by an instruction sequence under execution is a be- 
haviour to be controlled by some execution environment. It proceeds by perform- 
ing steps in a sequential fashion. Each step performed actuates the processing 
of an instruction by the execution environment. A reply returned by the execu- 
tion environment at completion of the processing of the instruction determines 
how the behaviour proceeds. Often, the processing of instructions takes place 
remotely. This means that, on execution of an instruction sequence, a stream of 
instructions to be processed arises at one place and the processing of that stream 
of instructions is handled at another place. The objective of the current paper is 
to bring this phenomenon better into the picture. To achieve this objective, we 
describe a basic protocol for instruction stream processing that deals with this 
phenomenon. 

The phenomenon sketched above is found if it is impracticable to load the 
instruction sequence to be executed as a whole. For instance, the storage ca- 
pacity of the execution unit is too small or the execution unit is too far away. 
The phenomenon requires special attention because the transmission time of the 
messages involved in remote processing makes it hard to keep the execution unit 
busy without intermission. The basic protocol for instruction stream processing 
is directed towards keeping the execution unit busy. There is no reason to use the 



word "remote" in a narrow sense. It is convenient to consider processing remote 
if it involves message passing with transmission times that are not neghgible. 
In that case, the basic protocol provides a starting-point for studies of basic 
techniques aimed at increasing processor performance, such as pre-fetching and 
branch-prediction, at a more abstract level than usual. Therefore, we consider 
the protocol relevant to the area of computer architectures. 

The work presented in this paper is a spin-off of the line of research with 
which a start was made in [5]. The working hypothesis of that line of research is 
that instruction sequence is a central notion of computer science. In that line of 
research, issues concerning the following subjects from the theory of computa- 
tion have been investigated from the viewpoint that a program is an instruction 
sequence: semantics of programming languages, expressiveness of programming 
languages, computability, computational complexity, and performance related 
matters of instruction sequences (see e.g. [8, 10, 11, 9, 7]). The description of the 
basic protocol for instruction stream processing starts from the behaviours pro- 
duced by instruction sequences under execution. By that we abstract from the 
instruction sequences which produce those behaviours. At the level of abstrac- 
tion concerned, it is easy to describe how the instruction streams are generated. 
How instruction streams can be generated efficiently from instruction sequences 
is another matter. 

Threads as considered in BTA (Basic Thread Algebra) are used in this pa- 
per to model the behaviours produced by instruction sequences under execution. 
BTA, introduced under the name BPPA (Basic Polarized Process Algebra) in [5], 
is a form of process algebra tailored to the description and analysis of the be- 
haviours produced by instruction sequences under execution. General process 
algebras, such as AGP [4, 2], GGS [15, 17] and GSP [12, 16], are too general for 
the description and analysis of the behaviours produced by instruction sequences 
under execution. That is, it is quite awkward to describe and analyse behaviours 
of this kind using such a general process algebra. However, the behaviours con- 
sidered in BTA can be viewed as processes that are definable over AGP, see 
e.g. [6]. This allows for the basic protocol for instruction stream processing to 
be described using AGP or rather AGP^, an extension of AGP which supports 
abstraction from internal actions. 

This paper is organized as follows. First, we give brief summaries of BTA 
(Section 2) and ACP^ (Section 3). Next, wc show how the behaviours considered 
in BTA can be viewed as processes that are definable over AGP^ (Section 4). 
Then, we describe the basic protocol for instruction stream processing (Section 5) 
and discuss some conceivable adaptations of the protocol (Section 6). Finally, 
we make some concluding remarks (Section 7). 

2 Thread Algebra 

In this section, we review BTA (Basic Thread Algebra) . BTA is concerned with 
behaviours as exhibited by instruction sequences under execution. These be- 
haviours are called threads. 
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Table 1. Axioms for guarded recursion 



{X\E) = {tx\E) \{ X = tx€E RDP 
E^X = {X\E) if X € V{E) RSP 



In BTA, it is assumed that a fixed but arbitrary set A of basic actions has 
been given. A thread performs basic actions in a sequential fashion. Upon each 
basic action performed, a reply from the execution environment of the thread 
determines how it proceeds. The possible replies are the Boolean values T and F. 

To build terms, BTA has the following constants and operators: 

— the deadlock constant D; 

— the termination constant S; 

— for each a E A, the binary postconditional composition operator ^a>. 

We assume that there are infinitely many variables, including x,y,z. Terms 
are built as usual. We use infix notation for the postconditional composition 
operator. Wc introduce basic action prefixing as an abbreviation: a o p, where 
a & A and p is a BTA term, abbreviates p<a>p. 

The thread denoted by a closed term of the form p<a>q will first perform 
a, and then proceed as the thread denoted by p if the reply from the execution 
environment is T and proceed as the thread denoted by q if the reply from the 
execution environment is F. The threads denoted by D and S will become inactive 
and terminate, respectively. This implies that each closed BTA term denotes a 
thread that will become inactive or terminate after it has performed finitely 
many basic actions. Infinite threads can be described by guarded recursion. 

A guarded recursive specification over BTA is a set of rcciirsion equations 
E = {X = tx \ X G V}, where is a set of variables and each tx is a BTA 
term of the form D, S or t <a> t' with t and t' that contain only variables 
from V. We write V(i?) for the set of all variables that occur in E. Wc are 
only interested in models of BTA in which guarded recursive specifications have 
unique solutions, such as the projective limit model of BTA presented in [3]. 

For each guarded recursive specification E and each X G V(£') , we introduce 
a constant {X\E) standing for the unique solution of E ior X. The axioms for 
these constants are given in Table 1. In this table, we write {tx\E) for tx with, 
for all Y G V(ii'), all occurrences of Y in tx replaced by {Y\E). RDP and 
RSP are actually axiom schemas in which X stands for an arbitrary variable, 
tx stands for an arbitrary BTA term, and E stands for an arbitrary guarded 
recursive specification over BTA. Side conditions are added to restrict what X, 
tx and E stand for. 

Let 9Jl be a model of BTA extended with guarded recursion. Then we use 
the term thread for the elements from the domain of EOT, and we denote the 
interpretations of constants and operators in OK by the constants and operators 
themselves. Moreoever, let p be a thread. Then the set of states or residual 
threads of p, written Res{p), is inductively defined as follows: 
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— p € Res{p); 

— if q <a>r G Res{p), then q e Res{p) and r G Res{p). 

We say that p is a regular thread if Res{p) is finite. Being a regular thread 

coincides with being the solution of a finite guarded recursive specification. 

In the sequel, we will make use of a version of BTA in which the following 
additional assumptions relating to A are made: (i) a fixed but arbitrary set 
of foci has been given; (ii) a fixed but arbitrary set A4 of methods has been 
given; (iii) A = {f-m \ f £ !F,m & M}. These assumptions are based on the 
view that the execution environment provides a number of services. Performing 
a basic action f.m is taken as making a request to the service named / to process 
command m. As usual, we will write B for the set {T, F}. 

3 Process Algebra 

In this section, we review ACP^ (Algebra of Communicating Processes with 
abstraction). This is the process algebra that will be used in Section 4 to make 
precise what processes are produced by the threads denoted by closed terms of 
BTA with guarded recursion. For a comprehensive overview of ACP^, the reader 
is referred to [2, 13]. 

In ACP^, it is assumed that a fixed but arbitrary set A of atomic actions, 
with T, (5 ^ A, and a fixed but arbitrary commutative and associative function 
I : A X A — > A U {6} have been given. The function | is regarded to give the result 
of synchronously performing any two atomic actions for which this is possible, 
and to give d otherwise. In ACP^, t is a special atomic action, called the silent 
step. The act of performing the silent step is considered unobservable. Because 
it would otherwise be observable, the silent step is considered an atomic action 
that cannot be performed synchronously with other atomic actions. 

ACP^ has the following constants and operators: 

— for each e e A, the atomic action constant e ; 

— the silent step constant r ; 

— the deadlock constant 6 ; 

— the binary alternative composition operator + ; 

— the binary sequential composition operator • ; 

— the binary parallel composition operator || ; 

— the binary left merge operator [[ ; 

— the binary communication merge operator | ; 

— for each H C A, the unary encapsulation operator Oh 

— for each / C A, the unary abstraction operator t/ . 

We assume that there are infinitely many variables, including x, y, z. Terms are 
built as usual. We use infix notation for the binary operators. 

Let p and q be closed ACP^ terms, e G A, and H,I C A. Intuitively, the 
constants and operators to build ACP^ terms can be explained as follows: 

— e first performs atomic action e and next terminates successfully; 
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Table 2. Axioms of ACP^ 



x + y = y + x 


Al 


a; • r = a; 




Bl 


{x + y) + z = x + {y + z) 


A2 


x-{T-{y + 


z) +y) = X ■ {y + z) 


B2 


X + X = X 


A3 








{x + y)-z = x- z + y- z 


A4 


Oh (a) = a 


if a ^ 


Dl 


{x ■ y) ■ z = X ■ {y ■ z) 


A5 


Oh {a) = S 


\f a£H 


D2 


X + 6 = x 


A6 


dH{x + y) -- 


= dH{x) + dniy) 


D3 


S ■ X = 5 


A7 


dnix ■ y) = 


dH{x) ■ dniy) 


D4 


X \\y = X W_y + y W_x + x\y 


CMl 


Ti{a) = a 


\f a^I 


Til 


a ]\_x = a ■ X 


CM2 


Ti{a) = T 


if o € / 


TI2 


a - x \[y = a ■ {x\\y) 


CMS 


Ti{x + y) = 


: Ti{x) + Tl{y) 


TI3 


{x + y)\lz = x\lz + y]lz 
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Ti{x -y) = 
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a ■ X \ b = {a\b) ■ X 
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{x + y)\z = x\ z + y\ z 
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x\{y + z)=x\y + x\ z 


CM9 


T \ a = 5 




C4 



— r performs an unobservable atomic action and next terminates successfully; 

— 5 can neither perform an atomic action nor terminate successfully; 

— p + q behaves either as p or as q, but not both; 

— p ■ q first behaves as p and on successful termination of p it next behaves 
as q; 

— p \\ q behaves as the process that proceeds with p and q in parallel; 

— p [[ g behaves the same as p \\ q, except that it starts with performing an 
atomic action of p; 

— p \ q behaves the same as p \\ q, except that it starts with performing an 
atomic action of p and an atomic action of q synchronously; 

— dnip) behaves the same as p, except that atomic actions from H are blocked; 

— T/(p) behaves the same as p, except that atomic actions from I are turned 
into unobservable atomic actions. 

The axioms of ACP^ are given in Table 2. CM2-CM3, CM5-CM7, C1-C4, 
D1-D4 and Til TI4 are actually axiom schemas in which a, h and c stand for 
arbitrary constants of ACP^, and H and / stand for arbitrary subsets of A. 
ACP^ is extended with guarded recursion like BTA. 

A recursive specification over ACP"^ is a set of recursion equations E = 
{X = tx \ X € F}, where V is a set of variables and c^aeh tx is an ACP^ term 
containing only variables from V. We write V(£') for the set of all variables that 
occur in E. Let t be an ACF"^ term without occurrences of abstraction operators 
containing a variable X. Then an occurrence of X in t is guarded if t has a 
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Table 3. Axioms for guarded recursion 



{X\E) = {tx\E) \{ X = tx€E RDP 
E^X = {X\E) if X € V{E) RSP 



subterm of the form e • t' where e € A and t' is a term containing this occurrence 
of X. Let S be a recursive specification over ACP^. Then _B is a guarded recursive 
specification if, in each equation X = tx & E: (i) abstraction operators do not 
occur in tx and (ii) all occurrences of variables in tx are guarded or tx can be 
rewritten to such a term using the axioms of ACP^ in either direction and/or 
the equations in E except the equation X = tx from left to right. We are only 
interested models of ACP^ in which guarded recursive specifications have unique 
solutions, such as the models of ACP^ presented in [2]. 

For each guarded recursive specification E and each X G V(£^), we introduce 
a constant {X\E) standing for the unique solution of E for X. The axioms for 
these constants arc given in Table 3. In this table, we write {tx\E) for tx with, 
for all Y e y{E), all occurrences of Y in tx replaced by {Y\E). RDP and 
RSP are actually axiom schemas in which X stands for an arbitrary variable, 
tx stands for an arbitrary ACP^ term, and E stands for an arbitrary guarded 
recursive specification over ACP^. Side conditions are added to restrict what X, 
tx and E stand for. 

We will write YliesP^^ where 5* = . . . , z„} and pi^, . . . ,pi^ are ACP^ 
terms, for + . . . + Pi„. The convention is that X^jggft stands for 6 if S = 9. 
We will often write X for {X\E) if E is clear from the context. It should be 
borne in mind that, in such cases, we use X as a constant. 

4 Process Extraction 

In this section, we use ACP^ with guarded recursion to make mathematically 
precise what processes are produced by the threads denoted by closed terms of 
BTA with guarded recursion. 

For that purpose, A and | are taken such that the following conditions are 
satisfied: 



A 3 {sf{d) \ f eJ^,deMuM}u {Tf{d) |/e:F,rfeAluB}u {stop, i} 

and for all / e ^, G A1 U B, and e e A: 
Sf{d) I Tfid) = i , 



The process extraction operation |_| determines, for each closed term p of 
BTA with guarded recursion, a closed term of ACP^ with guarded recursion 
that denotes the process produced by the thread denoted by p. The process 



Sf{d) \ e = S 
e I vf{d) = S 



if e 7^ Yfid) , 
if e 7^ Sf{d) , 



stop \ e = d , 
i\e = 6. 
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Table 4. Defining equations for process extraction operation 



ISI-^ = stop 

|D|" = i-5 

\U < f.rn> 121" = Sf{m) ■ (r^(T) ■ \ti\'' + r/(F) • 1*2^) 
\(X\E}\^ = {X\{Y=\tYnY = tY e E}) 



extraction operation |_| is defined by \p\ = T^stop}{\p\'^)j where l-j'^ is defined by 
the equations given in Table 4 (for / G ^ and m G Ai). 

Two atomic actions arc involved in performing a basic action of the form f.m: 
one for sending a request to process command m to the service named / and 
another for receiving a reply from that service upon completion of the processing. 
For each closed term p of BTA with guarded recursion. \p\'^ denotes a process 
that in the event of termination performs a special termination action just before 
termination. Abstracting from this termination action yields the process denoted 
by \p\. Some atomic actions introduced above arc not used in the definition of 
the process extraction operation for BTA. Those atomic actions are commonly 
used in the definition of the process extraction operation for extensions of BTA 
in which operators for thread-service interaction occur, sec e.g. [6]. 

Let p be a closed term of BTA with guarded recursion. Then we say that |p| 
is the process produced by p. 

The process extraction operation preserves the axioms of BTA with guarded 
recursion. Roughly speaking, this means that the translations of these axioms 
are derivable from the axioms of ACP^ with guarded recursion. Before we make 
this fully precise, we have a closer look at the axioms of BTA with guarded 
recursion. 

A proper axiom is an equation or a conditional equation. In Table 1, we 

do not find proper axioms. Instead of proper axioms, we find axiom schemas 
without side conditions and axiom schemas with side conditions. The axioms of 
BTA with guarded recursion are obtained by replacing each axiom schema by 
all its instances. 

We define a function |_ | from the set of all equations and conditional equations 
of BTA with guarded recursion to the set of all equations of ACP"^ with guarded 
recursion as follows: 

\tl=t2\ = |tl| = |t2|, 

\E^tl=t2\ = {\t[\ = \t'2\\t[^t'^ e E}^\ti\ = \t2\. 

Proposition 1. Let (f> be an axiom o/BTA with guarded recursion. Then {(pl is 
derivable from the axioms of ACP^ with guarded recursion. 

Proof. The proof is trivial. □ 

Proposition 1 would go through if no abstraction of the above-mentioned special 
termination action was made. Notice further that ACP'^ without the silent step 
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constant and the abstraction operator, better known as ACP, would suffice if no 
abstraction of the special termination action was made. 

5 A Protocol for Instruction Stream Processing 

In this section, we consider a protocol for instruction stream processing. Before 
the protocol is described, an extension of ACP is introduced to simplify the 
description of the protocol. 

The following extension of ACP from [1] will be used below: the non- 
branching conditional operator :— > over IB = {T, F}. The expression b is to 
be read as if 6 then p else S. The axioms for the non-branching conditional 
operator are 

T :— > a; = a; and F :— > a; = ^ . 

The protocol concerns a system whose main components are an instruc- 
tion stream generator and an instruction stream, execution unit. The instruction 
stream generator generates different instruction streams for different threads. 
This is accomplished by starting it in different states. The general idea of the 
protocol is that: 

— the instruction stream generator generating an instruction stream for a 
thread of the form t <a> t' sends a to the instruction stream execution 
unit; 

— on receipt of a, the instruction stream execution unit gets the execution of 
a done and sends the reply produced to the instruction stream generator; 

— on receipt of the reply, the instruction stream generator proceeds with gen- 
erating an instruction stream for t if the reply is T and for t' otherwise. 

In the case where the thread is S or D, the instruction stream generator sends a 

special instruction (stop or dead) and the instruction stream execution unit does 
not send back a reply. The specifics of the protocol considered here arc that: 

— the instruction stream generator may run ahead of the instruction stream 
execution unit by not waiting for the receipt of the replies resulting from the 
execution of instructions that it has sent earlier; 

— to ensure that the instruction stream execution unit can handle the run- 
ahead, each instruction sent by the instruction stream generator is accom- 
panied with the sequence of replies after which the instruction must be exe- 
cuted; 

— to correct for replies that have not yet reached the instruction stream gen- 
erator, each instruction sent is also accompanied with the number of replies 
received since the last sending of an instruction. 

We write A' for the set {stop, dead}. Elements from A' will loosely be 
called instructions. 
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Henceforth, it is assumed that a model of BTA extended with guarded recur- 
sion has been given. The restriction of the domain of that model to the regular 
threads will be denoted by TZT. 

The functions act, thrt, and thrf defined below give, for each thread t different 
from S and D, the action that t will perform first, the thread with which it 
will proceed if the reply from the execution environment is T, and the thread 
with which it will proceed if the reply from the execution environment is F, 
respectively. The functions act -.TIT A', thrtiTZT TIT, and thrf -.TIT TIT 
are defined as follows: 

act{S) = stop , thrt{S) = D , thrf{S) = D , 

act{D) = dead , thrt{D) = D , thrf{D) = D , 

act{t<la>t') = a , thrt{t <\a\>t') = t , thrf{t<a>t')=t'. 

We write B^", where n e N, for the set {u € B* | len{u) <n}} 

It is assumed that a natural number i has been given. The number £ is taken 

for the maximal number of steps that the instruction stream generator may run 

ahead of the instruction stream execution unit. 

The set T^A of instruction messages is defined as follows: 

IM = [0, £] X B^^ X A' . 

In an instruction message (n, u.a) G XA4: 

— n is the number of replies that is acknowledged by the message; 

— u is the sequence of replies after which the instruction that is part of the 

message must be executed; 

— a is the instruction that is part of the message. 

The instruction stream generator sends instruction messages via an instruction 
message transmission channel to the instruction stream execution unit. We refer 
to a succession of transmitted instruction messages as an instruction stream. An 
instruction stream is dynamic by nature, in contradistinction with an instruction 
sequence. 

The set <Sisg of instruction stream generator states is defined as follows: 
S,sG = [0,e]xV{M^^+^ xTlT) . 
In an instruction stream generator state (n, R) £ Sisg- 

— n is the number of replies that has been received by the instruction stream 
generator since the last acknowledgement of received replies; 

— in each (u, p) & R, u is the sequence of replies after which the thread p must 
be performed. 

^ As usual, we write D* for the set of all finite sequences with elements from set D 
and len{a) for the length of finite sequence a. Moreover, we write e for the empty 
sequence, d for the sequence having d as sole element, aa' for the concatenation of 
finite sequences a and a', and tl{a) for the tail of finite sequence a. 
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The functions updprn and updcr defined below are used to model the updates of 
the instruction stream generator state on producing a message and consuming 
a reply, respectively. The function updpm : (B-^ x TZT) x »Sisg — > >5isg is defined 
as follows: 

updpm {{u, p), (n, R)) = 



The function updcr : B x >Sisg —>■ Sisg is defined as follows: 

updcr{e, (n, R)) = (n + 1, {{u,p) \ {eu,p) G R]) . 

The function sel defined below is used to model the selection of the sequence of 
replies and instruction that will be part of the next message produced by the 
instruction stream generator. The function sel : V{M^^ x TZT) P(B^^ x TZT) 
is defined as follows: 

sel{R) = {(u,_p) e R I V(w, q) e R' len{u) < len{v) A len{u) < £} . 

Notice that (u.p) e sel(R) and (u, q) E R only if u < v. By that depth-first nm- 
ahead is excluded. It happens that the performance of the protocol may change 
considerably if the function sel is replaced by another function. 

The set <Siseu of instruction stream execution unit states is defined as follows: 



In an instruction stream execution unit state (n, S) £ «Siseu: 

— n is the number of replies for which the instruction stream execution unit 
still has to receive an acknowledgement; 

— in each {u, a) G S, u is the sequence of replies after which the action a must 
be executed. 

The functions updcm and updpr defined below are used to model the updates of 

the instruction stream execution unit state on producing a reply and consuming 
a message, respectively. The function updcm : IM. x <Siseu ^ '^iseu is defined as 
follows: 



The function updpr : B x iSiseu ^ i^iseu is defined as follows; 

updpr(e, (n, S)) = (n + 1, {(u, a) \ (en, a) G S}) . 

The function nxt defined below is used to distinguish between the execution of 
a basic action a€: A, which leads to a reply, and the execution of S or D, which 

^ W"(w) is defined by induction on n as usual: tf{u) = u and W"+^(m) = tl{tl"^'^{u)). 




5isEu = [0,^]xP(B^^x^')- 



updcm{(k, u, a), (n, S)) = (n — k, S U {{tf' '^(u), a)}) 
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leads to termination or inaction. The function nxt : A' x P(B-^ x A') ^ B is 
defined as follows: 

nxt(a, S) = < ^ ^ 

^ ' \f \f{e,a)^S. 

Notice that the set B = {T, F} is the set of replies. The instruction stream 

execution unit sends replies via a reply transmission channel to the instruction 
stream generator. We refer to a succession of replies as a reply stream. 

For the purpose of describing the transmission protocol in ACP^, A and | 
are taken such that, in addition to the conditions mentioned at the beginning of 
Section 4, the following conditions are satisfied: 

A 2 {Si{d) \ 2}, d £ JM} U {Ti{d) \ i e {I, 2}, d e IM} 

U {Si(e) \ 4}, e e B} U {ri(e) | i G {3, 4}, e e B} U {j} 

and for aU i e {1, 2}, j G {3, 4}, d G IM, e e B, and e e A: 

s,(d) I rj(d) = j , Sj{e)\Tj{e) = } , 

Si{d)\e = S \fe^Ti{d), Sj{e)\e = S \fe^Tj{e), 

e I ri{d) =6 if e 7^ Si{d) , e\rj{e) = S if e 7^ Sj(e) , 

j I e = (5 . 

Let p G TZT. Then the process representing the basic protocol for instruction 
stream processing with regard to thread p is described by 

dnilSGp II IMTC \\ RTC \\ ISEU) , 

where the process ISGp is recursively specified by the following equations: 

ISGp = /S'G'(o^{(j p)}) , 

iu,p)esel{R) 

eeB 

(for every (n, R) £ iSisg with i? 7^ 0) , 

(for every (n, 0) e <Sisg) , 
the process IMTC is recursively specified by the following equation: 
IMTC = ri(^) ■ S2(rf) ■ IMTC , 

delM 
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the process RTC is recursively specified by the following equation: 
ETC = r3(e) • S4(e) • RTC , 

eeB 

the process ISEU is recursively specified by the following equations: 
ISEU = ISEUlo^^^ , 

delM 

+ nxtif.m,S):^Sf{m)-ISEUli,^s) 

f.meA 

+ nxt{stop, S) :^ stop + ra<(dead, 5) :— > i • 5 
(for every (n, 5) £ 5iseu) , 

ISEUl'^^S) = E '^/(e) • S3(e) • /5Ef/Ur(e,(n,S)) 

eeB 

+ E ^2(d) • ISEU^p^^^(^^^(^„^s)) 

delM 

(for every (n, 5) e iSiseu) , 

and 

H = {s,id) I i e {1, 2}, d G IM} U {r,(d) M £ {1, 2}, d G 
U {Si(e) I i G {3, 4}, e G 1} U {ii{e) | i G {3, 4}, e G B} . 

/S'Gp is the instruction stream generator generating an instruction sequence for 
thread p, IMTC is the instruction message transmission channel, RTC is the 
reply transmission channel, and ISEU is the instruction stream execution unit. 

The protocol described above has been designed so as to satisfy the following 
equation: 

T-\p\=T- Ts^^{dH{ISGp II IMTC II RTC \\ ISEU)) . 

We refrain from proving that the protocol satisfies this equation since this paper 
is first and foremost a conceptual paper. 

The transmission channels IMTC and RTC can keep one instruction message 
and one reply, respectively. The protocol has been designed in such a way that 
the protocol will also work properly if these channels are replaced by channels 
with larger capacity and even by channels with unbounded capacity. 

6 Adaptations of the Protocol 

In this section, we discuss some conceivable adaptations of the protocol described 
in Section 5. 
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Consider the case where, for each instruction, it is known what the probabiUty 
is with which its execution leads to the reply T. This might give reason to 
adapt the protocol described in Section 5. Suppose that the instruction stream 
generator states do not only keep the sequences of replies after which threads 
must be performed, but also the sequences of instructions involved in producing 
those sequences of replies. Then the probability with which the sequences of 
replies will happen can be calculated and several conceivable adaptations of the 
protocol to this probabilistic knowledge are possible by mere changes in the 
selection of the sequence of replies and instruction that will be part of the next 
instruction message produced by the instruction stream generator. Among those 
adaptations are: 

— restricting the instruction messages that are produced ahead to the ones 

where the scqiicnce of replies after which the instruction must be executed 
will happen with a probability > 0.50, but sticking to breadth-first run- 
ahead; 

— restricting the instruction messages that are produced ahead to the ones 
where the sequence of replies after which the instruction must be executed 
will happen with a probability > 0.95, but not sticking to breadth-first run- 
ahead. 

Rcgiilar threads can be represented in such a way that it is effectively dccid- 
able whether the two threads with which a thread may proceed after performing 
its first action are identical. Consider the case where threads are represented in 
the instruction stream generator states in such a way. Then the protocol can be 
adapted such that no duplication of instruction messages takes place in the cases 
where the two threads with which a thread possibly proceeds after performing 
its first action arc identical. This can be accomplished by using sequences of 
elements from B U {*}, instead of sequences of elements from B, in instruction 
messages, instruction stream generator states, and instruction stream execution 
unit states. The occurrence of * at position « in a sequence indicates that the 
ith reply may be either T or F. The impact of this change on the updates of 
instruction stream generator states and instruction stream execution unit states 
is minor. 

7 Conclusions 

We have described a basic protocol to deal with the phenomenon that, on execu- 
tion of an instruction sequence, a stream of instructions to be processed arises at 
one place and the processing of that stream of instructions is handled at another 
place. By that we have brought this phenomenon better into the picture. We 
have also discussed some conceivable adaptations of the basic protocol. 

The description of the protocol starts from the behaviours produced by in- 
struction sequences under execution. By that we abstract from the instruction 
sequences which produce those behaviours. How instruction streams can be gen- 
erated efficiently from instruction sequences is a matter that obviously requires 
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investigations at a less abstract level. The investigations in question are an option 
for future work. 

We believe that the protocol described in this paper provides a setting in 
which basic techniques aimed at increasing processor performance, such as pre- 
fetching and branch-prediction, can be stiidicxi at a more abstract level than 
usual (cf. [14]). In particular, we think that the protocol can serve as a starting- 
point for the development of a model with which trade-offs encountered in the 
design of processor architectures can be clarified. We consider investigations into 
this matter an interesting option for future work. 
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